Note that because of the nature of the Flags field, and the existence of universal flags, having the tfLoanBrokerPrivate field unset should be ignored - not treated as trying to change the flag.

Conversely, if the flag is set, that should always return as temINVALID regardless of the state of the LoanBroker object. (If it's already set, then the flag is redundant. If it's not set, then that's an attempted change.) At the implementation level, that means this check can be done in preflight - you don't need to know the current state of the LoanBroker object.

So I would suggest rephrasing this as something like

The `tfLoanBrokerPrivate` flag is set in the transaction

Info: Since there are no other ledger flags defined for the loan broker object, this means that the Flags field can not be changed, and so this can be checked in NoModifiedUnmodifiableFields.

@a1q123456 fyi.

This is a protocol-level check, because it requires loading the LoanBroker.Owner's account root and/or signers list. For example, the owner may have a regular key defined. The transactor can't know that the regular key is allowed to sign for the owner without loading AccountRoot(LoanBroker.Owner) to get the sfRegularKey field.

If the signer(s) in the CounterpartySignature is/are not allowed, the failure code will be a tef, depending on which failure case is hit. e.g. tefMASTER_DISABLED, tefBAD_AUTH, tefNOT_MULTI_SIGNING, tefBAD_SIGNATURE, tefBAD_QUORUM. There may be others.

temBAD_SIGNER is only relevant to LoanSet if

1. it's a Batch inner tx and theCounterparty is not set, or
2. if it's a normal tx and there is no CounterpartySignature at all, or
3. if there is no Counterparty set and the LoanBroker(LoanBrokerID) doesn't exist on ledger.

Yep, I captured the other temBAD_SIGNER errors, and moved this particular failure down to protocol checks.